A web mashup is a website or web application that seamlessly combines content (such as data and code) from multiple sources (which may even be competing sources) into an integrated experience for a user. For example, a real estate website may combine map data from one website with housing data from another website to present an integrated view of housing prices at various locations on a map. Web mashups may also involve gadgets, which are miniature objects offering dynamic content that can be placed on any page on the web. Gadget aggregators (such as Microsoft® Windows Live) aggregate gadgets into a single page to provide a desirable, single-stop information presentation to their users.
In order for mashups to bring together content from multiple sources, they need to circumvent the security measures contained in browsers. Security measures, such as the same-origin web security model, allow web browser users to view interactive content without completely trusting the owner of that content. This security model keeps an untrusted web page from observing or corrupting the user's actions at other sites and from issuing unwanted transactions on behalf of the user. The same-origin web security model states that “only the site that stores some information in the browser may read or modify that information.”
The same-origin web security model restrictions that are of greatest interest to web mashups are script (for example, JavaScript®, ECMAScript, and Jscript®) restrictions that regulate access to inline frames (IFRAMEs) and the XML-HttpRequest object. An IFRAME is an HTML element that makes it possible to embed another HTML document inside the main document. The embedded document can be a different document from the main document, and can be embedded without reloading the main document.
Inline frames can be used to download rich HTML documents from outside sources, but if the content comes from a different domain the browser will not allow the script in the containing page to read or manipulate the document inside the frame, and vice versa. The XML-HttpRequest can be used to download arbitrary XML documents without rendering them in a browser pane, but it cannot be used to download files that are not from the same domain as the page making the request. By enforcing these restrictions, the script same-origin policy protects the secrecy of HTML documents that the user has access to, and also protects the integrity of a page against unauthorized modifications by other pages.
Web developers often are forced to choose between security and functionality. Functionality is improved when unfettered access is giving to websites. However, this approach incurs high security risks because one site gets complete control over the other. Moreover, the browser can be extended with plug-ins for cross-domain interactions. This approach has the disadvantage of being inconvenient for users whose browsers are not supported by the plug-in or who are unwilling to install new software.
One current technique used by mashups to communicate across domains is by using proxies. The website hosting the mashup can host a URL which relays data between the client and the source of the data. These proxies (sometimes known as bridges) make the data appear to the client to be “same-origin” data, so that the browser allows this data to be read back out of an IFRAME, or more commonly, an XMLHttpRequest. One disadvantage of this approach is that it adds the latency of connecting through a mashup's proxy server, which generally takes longer than connecting directly to the server hosting the data. In addition, bandwidth costs for the mashup author are increased by the proxy approach, particularly if the size of the mashup's code is small relative to the amount of cross-domain data being proxied. Moreover, although these proxies only go to one place, because they are left open for anyone to use, they provide another layer for hackers to hide behind for denial of service or exploiting input validation vulnerabilities on the server hosting the data source.
Another technique used by mashups to communicate across domains is cross-domain script tags. The same-origin policy on script protects HTML documents loaded from other domains, but it does not apply to scripts, which can be loaded from other domains and executed with the privileges of the page that included them. These remote scripts can be added to a page dynamically, allowing new data to be loaded into part of a page without forcing the entire page to be loaded. Unlike an XMLHttpRequest, which provides full read access to the content being requested, a script can only be accessed by executing it. This restriction ensures that only valid script files can be accessed across domain boundaries, while all other files (such as HTML documents) will cause a syntax error.
One disadvantage of using cross-domain script tags is that execute-only access requires that the page including the script fully trusts the source of the script. Another disadvantage is that the page including the script has no way of performing input validation to ensure that the script being retrieved is not misusing its access to the parent page. The site hosting the script could change the content of the script at any time, and could even serve different scripts to different users. Other cross-domain tags that can transmit information include stylesheets, which have the same security issues as scripts, and images, which can transmit limited information through height and width.
Another technique used by mashups to communicate across domains is by using fragment identifier messaging. Each browser has certain objects in the browser that can be accessed despite that object belonging to another domain. One example is the window.location object, which can be set (but not read) by frames of another origin. Thus, if a frame from Site A can access a frame of a page from Site B, it can pass a message to Site B by setting the location of Site B's page to be equal to Site B's current location plus a fragment identifier (starting with #). Because browsers do not reload the page when navigating to a fragment, the Site B page is not interrupted, but can receive the message without any network requests being sent. This technique is known as fragment identifier messaging, and has been used by some mashups to pass information on the client side between frames. Unfortunately, fragment identifier messaging requires careful synchronization between the communicating pages, and can be easily disrupted if the user presses the browser's back button.